Add generic Snapdragon X support on aarch64 - #8672

The previous guard skipped the pacman.conf restore on aarch64 on the grounds
that Omarchy's config points at x86-only repositories. But at that point the
target still carries the live ISO's pacman.conf, which knows only the offline
mirror, and that directory does not exist on the installed system. Skipping
therefore left every aarch64 install unable to run pacman at all, which is the
outcome the guard claimed to prevent.

Derive the config from Omarchy's template instead: drop [multilib], keep
[omarchy] (its $arch placeholder resolves correctly), add Arch Linux ARM's
[alarm] and [aur] repositories, and leave the mirrorlist the distribution
installed rather than replacing it with Omarchy's x86_64 mirror of Arch. The
x86_64 path is unchanged.

Snapdragon laptops boot with the device tree for their exact model and the
firmware provides none. The live ISO already boots them with a systemd-stub
UKI that carries every candidate tree as .dtbauto sections and picks one by
SMBIOS hardware id; the installed system built its UKIs with no tree at all,
so the first reboot after the install had nothing to boot.

Add the omarchy-hw-qualcomm-soc probe (root device-tree compatible starts
with qcom,) and a hardware leaf that lists the trees in /etc/kernel/uki.conf,
which mkinitcpio hands to ukify for every UKI limine-mkinitcpio-hook builds.
The list is a snapshot of /boot/dtbs/qcom taken when the leaf runs; the file
header says so, and the enumeration retires when ukify accepts globs.

The same set Fedora's Snapdragon images and the live ISO carry, as a
limine-entry-tool drop-in so limine-update folds it into every entry, with
each parameter's reason and retirement condition in the file.

Adreno GPUs are platform devices, so the lspci vendor scan in vulkan.sh
never sees them; ask the SoC probe instead.

…s exist

Arch Linux ARM keeps the redistributable Qualcomm blobs in
linux-firmware-qcom; the installed system had none of them. The vendor-signed
DSP firmware comes later from the owner's Windows partition; until it is
there the DSP driver's failing probe resets the USB-C mux, which drops a
USB-C root disk and hangs the boot (seen on the HP EliteBook Ultra G1q).

install/hardware/qualcomm/firmware.sh installs qcom-firmware-extract next to
linux-firmware-qcom and runs it in the target: the files the device tree
names (GPU zap shader, audio and compute DSP images) are taken from the stage
the ISO saved before the disk was written, or from a Windows partition still
on disk, into /usr/lib/firmware/updates. The audio-DSP blacklist now follows
what is actually missing (qcom-firmware-extract --list-missing) instead of a
path glob, so it clears itself once the firmware is present.

install/omarchy-other.packages lists qcom-firmware-extract (arch=any) so the
offline mirror carries it.

With real DSP firmware the Type-C port controller takes over the ports once
the ADSP is up and resets them, which drops a root disk behind a USB-C port
(G1q, external NVMe: cdsp up at 10.8 s, I/O errors and a read-only root at
22 s). Installs whose root disk reports TRAN=usb keep qcom_q6v5_pas
blacklisted (no audio or battery reporting) until the kernel stops resetting
connected ports; internal-disk installs are unchanged.

The final pacman restore is skipped entirely on ARM, which leaves the
installed system pointed at the live ISO's offline config -- a file:// repo
under a bind mount that only exists during the install. The first thing a new
aarch64 desktop does is fail:

  $ sudo pacman -Sy evtest
  failed retrieving file 'offline.db' from disk: Could not open file
  /var/cache/omarchy/mirror/offline/offline.db

No pacman -S, no omarchy-update. The skip was right that Omarchy's channel
configs cannot be applied on ARM -- [core]/[extra] come from Omarchy's mirror
of Arch, which builds x86_64 only, [multilib] is 32-bit x86, and the Omarchy
package repository serves no aarch64 tree -- but the configuration it keeps
instead is the offline one, so it trades a broken config for no config.

Restore Arch Linux ARM's repositories there instead: [core] [extra] [alarm]
[aur], its stock set, through a mirrorlist of its own because ALARM serves
$arch/$repo where Arch serves $repo/os/$arch. [options] is kept byte-identical
to the x86_64 channel configs. [omarchy] is left out until that tree exists;
including it would 404 on every sync, and Omarchy's own packages simply hold
at the versions the ISO installed.

Three further things the restore has to do that the x86_64 path does not:

- Take archlinuxarm-keyring while the offline mirror is still the active
  source. Arch's `base` pulls in archlinux-keyring and nothing pulls in this
  one, and the repositories being written are unreachable during an offline
  install.

- Write the mirrorlist unconditionally. The target's mirrorlist carries
  Omarchy's and Arch's x86_64 mirrors ahead of ALARM's, so a sync logs 404s
  from mirror.omarchy.org, mirror.rackspace.com and geo.mirror.pkgbuild.com
  before it finds anything.

- Populate the keyring. The install leaves ALARM's build key untrusted on the
  target, so the first signed install fails with "Arch Linux ARM Build System
  <builder@archlinuxarm.org> is unknown trust".

x86_64 keeps running the same two lines it ran before, and every other
architecture keeps the behaviour it had before the skip was introduced.